Обсуждение:Графовая база данных

Слайды как АИ?

Автор упорно добавляет в качестве АИ презентацию [1]. Необходимость этого не показана, т.к во-первых, презентация -- не самостоятельный документ, он всегда является частью доклада. Например, на слайде может быть написано: X, Y, Z, а докладе устно сказано: «существуют распространённые заблуждения, показанные на слайде, что X, Y и Z, но это неверно потому-то и потому-то». То есть слайды что-то показывают, что но именно без текста нужно лишь гадать. Во-вторых, у данного автора уже есть солидная публикация, так зачем ещё и презентацию помещать? Евгений Мирошниченко 03:17, 21 мая 2012 (UTC)

Почему упорно? вот если вы сейчас отмените и затем я, то уже упорно, а пока мы даже не превысили правило трёх откатов. Если удаляете источник удаляйте правильно. Источник является АИ по данной тематике, так как доклад сделан специалистом на школе-конференции посвящённой тематике упомянутой в статье. Во вторых презентация, не самостоятельна, а везде идёт дублирующим источником с научной статьей этого же автора. Godligift 04:27, 22 мая 2012 (UTC)

Упорно, потому что вносите второй раз. И по существу моих аргументов вы ничего не сказали. В качестве источника в статью вы предлагаете набор слайдов (презентацию), а пишете о докладе. Презентация и доклад — не одно и то же, о чём я написал выше. Это тут можно сколько угодно повторять про «доклад», про «школу-конференцию» — но пока что в качестве АИ вы предоставляете вовсе не доклад на школе-конференции, а набор слайдов. Далее, про «везде идёт дублирующим источником» — а вы прочитали моё предыдущее сообщение? Я как раз и написал, что у данного автора уже есть солидная публикация. Вы что, пытаетесь «подкрепить» авторитетный источник неавторитетным? Или невторитетный — авторитетным? Это очень странно. В любом случае, в Википедии место только авторитетным источникам. Евгений Мирошниченко 06:33, 22 мая 2012 (UTC)

Замените презентацию на публикацию. Я этому точно мешать не буду и только приветствую. Godligift 13:04, 22 мая 2012 (UTC)

Так ссылка на публикацию в статье уже есть. Обсуждается ссылка на презентацию. Евгений Мирошниченко 01:21, 23 мая 2012 (UTC)

Во вторых автору не понятно, по каким причинам он должен доказывать очевидное утверждение. Граф базы это не SQL и поэтому они NoSQL и АИ тут не требуются, если вы сможете привести пример баз данных, которые являются не SQL и NoSQL я соглашусь с вашими претензиями на АИ этого утверждения, иначе вы просто стараетесь внести не существенные и противоречивые правки, которые ведут к ВП:ВОЙ. Если так продолжиться я попрошу администрацию вступить по статье в качестве посредников. Godligift 04:27, 22 мая 2012 (UTC)

Очевидным это утверждение является только в ваших глазах. В моих, например, не обязательно (как минимум потому, что авторитетного определения NoSQL вообще не существует в природе). А раз так, смотрим правила ВП:ПРОВ: Авторы статей должны указывать авторитетные источники для цитат и другой информации, которая ставится или может быть поставлена под сомнение. В случае, если были высказаны сомнения относительно достоверности приведённых в статье сведений, ссылки на источники информации должен предоставить тот участник, который добавил в статью новые или восстановил ранее удалённые сведения. Вот и укажите, пожалуйста. Либо уберите сомнительную часть фразы, как это сделал я. Евгений Мирошниченко 06:32, 22 мая 2012 (UTC)

Хорошо напишите что это SQL-базы данных... Вперед. Доведите до абсурда. Я же ничего доказывать не буду. Я написал статью которой не было и которая по моему мнению должна была быть. Считаете иначе, выставляйте на БУ, удаляйте текст, так сказать правьте смело,... Godligift 13:04, 22 мая 2012 (UTC)

Вообще-то обсуждается лишь кусок определения из преамбулы. К чему этот трагизм, мол «выставляйте на БУ». Если бы я считал, что статью надо удалить, я бы так давно и сделал. Но я так не считаю.

В данном случае ситуация простая: есть конкретное сомнительное утверждение, на которое нет источника, и таковой источник вы, как я понял, предоставить не можете. Следовательно, утверждение подлежит удалению, что я делал ещё в этой правке [2]. Замечу, что требование проверяемости неочевидных утверждений — не моя прихоть, я одно из базовых правил Википедии. И мне непонятно, почему вы так остро реагируете на простую и очевидную просьбу предоставить АИ. Я глянул, вы в Википедии не со вчерашнего дня, а уже целый год, то есть правила и традиции хорошо должны знать, верно?

Что касается «правьте смело»: я точно так и делал, но после вами отмены моих правок правило Википедия:Правьте смело уступает место правилу Википедия:Консенсус. Скажите, я правильно понял, что по обоим пунктам мы договорились (ссылку на презентацию убрать, сомнительную часть определения убрать)? Евгений Мирошниченко 01:21, 23 мая 2012 (UTC)

Второе не согласен - очевидный факт в контексте статьи, первое я не против... Godligift 16:04, 23 мая 2012 (UTC)

Я процитировал вам конкретные указания из правил, которые требуют от вас привести АИ. АИ вы приводить отказываетесь и убирать спорное утверждение тоже. То есть вы прямо и сознательно нарушаете правила. Ну хорошо, я найду посредника, посредник спросит у вас АИ, АИ у вас нет, посредник удалит этот кусок. Нет, даже проще, тут и посредник не нужен. Я просмто подожду положенные две недели, пока повисит шаблон запроса АИ, а через две недели удалю утверждение в полном соответствии с правилами. Только будет лишняя затрата времени и нервов. Зачем? Проще сразу убрать. Евгений Мирошниченко 01:12, 24 мая 2012 (UTC)

Мда, следовать букве, а не духу правил. Если дословно следовать правилам, то многие статьи вообще попадут в "правовой" вакуум, а другие будут пресыщены противоречивыми правилами. Godligift 04:01, 24 мая 2012 (UTC)

Вы не слышите чужую точку зрения или специально её игнорируете? Спасибо что предупредили про две недели. Я найду посредника. Godligift 04:01, 24 мая 2012 (UTC)

Не слышу? А зачем же я тогда вам правила цитировал? Ваша точка зрения противоречит правилам, что вы выше косвенно подтвердили, сетуя, что я следую «букве, а не духу правил». Труд по организации посредничества со 100% вероятностью будет бесполезен, так как ни один посредник не станет грубо нарушать правила. Впрочем, воля ваша. Евгений Мирошниченко 06:06, 24 мая 2012 (UTC)

[3], [4] и т.д. и т.п. Как я говорил в контексте этой статьи это утверждения очевидно, а учитывая, что в статьях NoSQL в руск и англ википедиях, эти базы выделены в подкласс NoSQL очевиден в двойне. Если вы против найдите ссылку на противоположную точку зрения. Godligift 07:23, 24 мая 2012 (UTC)

По первой ссылке классифицирована одна конкретная СУБД. По второй приведено мнение одного человека, Emil Eifrem, что вряд ли можно счесть чем-то большим, чем мнение. Что касается статей про NoSQL в РуВики и англовики, то с ними есть огромная проблема. Все они написаны по неавторитетным источникам, а уж откуда эти списки берутся, один Бог ведает. Сайт nosql-database.org, с которого эти списки приходят, — это вообще не пойми что, полуграмотная свалка информации неустановленного авторства и авторитетности. Кстати, в статье англовики en:Graph database про NoSQL ничего нет Евгений Мирошниченко 08:48, 24 мая 2012 (UTC)

Это были первые две ссылки по запросу "graph data base nosql" Ну скажите какие? Они тогда SQL-базы данных? NoSQL - обозначает неSQL куда они подходят. Godligift 09:27, 24 мая 2012 (UTC)

Правьте статьи по NoSQL в обоих Википедиях, предъявляйте претензии и там тоже. Ваша упование на АИ напоминает мне картинку из Викиреальности про АИ... Godligift 09:27, 24 мая 2012 (UTC)

[5] - конференция по NoSQL, графовые базы данных вынесены в отдельную секцию Godligift 09:37, 24 мая 2012 (UTC)

[6] - еще одна. Думаю доказывать мне больше ничего не нужно... И я думаю в контексте статьи данное утверждение очевидно. Godligift 09:39, 24 мая 2012 (UTC)

И что эти ссылки показывают? Собрался междусобойчик разработчиков некоторых систем. Это же не теоретический и даже не общепризнанный уровень. Никто не спорит, что члены сообщества NoSQL норовят к себе записать все системы, графовые СУБД в т.ч., что сделать им позволяет полное отсутствие определения NoSQL, однако это не означает, что это мнение сколько-то теоретически подкреплено. Тут нужны работы исследователей, учёных, экспертов. А не программистов. Евгений Мирошниченко 11:23, 24 мая 2012 (UTC)

Я это утверждение перечитал три раза и таки не понял, что именно утверждается — «графовая база данных может быть реализована средствами NoSQL» или «графовая база данных не может быть реализована средствами SQL»? Если первое — то надо так и сформулировать и тогда тогда подтверждением станет любая реализация. Если второе — то это если не чайник Рассела, то как минимум довольно небанальное утверждение хотя бы потому, что даже отсутствие успешных SQL-реализаций не означает, что такие реализации невозможны в принципе. Я уж не говорю о том, что таковое отсутствие нужно подтверждать очень авторитетным источником, потому что из того, что реализация неизвестна автору не следует, что её не существует. Дядя Фред 10:39, 24 мая 2012 (UTC)

Участник ‎Krassotkin исправил определение, так что оно теперь хорошо определяет сущность этих баз данных. Однако тут дело в понимании вопроса. Граф модкль баз данных является сетевой моделью и не является Реляционной моделью данных(SQL). Вот и все. Я указывал, что доказывать очевидные факты следующие из контекста не надо. Godligift 10:48, 24 мая 2012 (UTC)

Я опять ничего не понял. Термин «графовая» описывает математическую модель базы данных, а термин «реляционная» — принцип построения. Так что утверждение «графовая база данных не может быть реляционной» сродни утверждению «металл не может быть зелёным» — оно, может, и верно, но далеко не банально. Дядя Фред 12:55, 24 мая 2012 (UTC)

А по вашему, реляционные БД к NoSQL не могут принадлежать, что ли? Дык давно уже NoSQL стали трактовать как Not Only SQL (чем ещё больше запутали, на самом деле). Сейчас в SQL-СУБД и Map/Reduce есть, и ACID может не быть. Далее, реляционные БД и SQL -- они не одно и то же. Язык SQL -- он вообще-то только одна из реализаций, но не единственная. Евгений Мирошниченко 11:23, 24 мая 2012 (UTC)

Кстати, не уверен, что обязательно нужно «дожимать». Вполне можно помочь добрым словом, советом или своей, более качественной ссылкой на источники. Тем более, что непосредственная причина разногласий из текста убрана и обсуждение плавно перетекает в высоконаучные теоретические аспекты. Поэтому предлагаю закрыть эту ветку, если никто не возражает, конечно. --cаша (krassotkin) 11:46, 24 мая 2012 (UTC)

• (не очень получается вникнуть в суть вопроса именно сейчас) Слишком много обсуждений очень короткого текста! Могу пока сказать только две вещи. Первое: презентации могут использоваться только в качестве дополнительного иллюстративного материала по теме. Второе: существует реляционная модель базы данных, а есть модели, основанные на других принципах (сетевые, иерархические); каковы принципы — таковы и принципы построения. Другое дело, что мы можем моделировать одно с помощью другого. Это, если коротко. --OZH 20:16, 24 мая 2012 (UTC)

Название

Термин Graph database сейчас передан как «Базы данных на основе графов». Это очень громоздко, неудобно и неверно, т.к. «на основе графов» по английски будет „graph-based“. Я не понимаю, почему бы не использовать стандартное прилагательное «графовый», то есть «графовые базы данных»? Ведь штатные термины же: графовый алгоритм, графовый подход, графовый анализ, графовый код, графовый морфизм... Евгений Мирошниченко 01:29, 24 мая 2012 (UTC)

Просто не смог корректно перевести и не более, а выражение "граф базы данных", которое я видел в обиходе, считал не верным. Ваше предложение очень хорошее, оно намного лучше чем мой перевод. Не возражаю против переименования(чтобы вы лишний раз не спрашивали)Godligift 04:05, 24 мая 2012 (UTC)

• Название статьи должно опираться на авторитетный источник. Чего нет даже в английском варианте. Графовые базы данных, видимо, можно считать обобщением сетевых баз данных, но в чём заключается обобщение? Если устоявшегося термина нет, то и описывать следует соответствующим образом. --OZH 19:59, 24 мая 2012 (UTC)

  Ну, поиск по "графовая БД" даёт немало ссылок, например вот: [7]. Докладик г-на Голова В.А. на конференции конечно малограмотный (товарищ категорически не различает модель и реализации, а иногда просто гонит), но показывает, что термин «графовые базы данных» вполне на русском языке употребляется. Евгений Мирошниченко 02:01, 25 мая 2012 (UTC)

  Англ термин вполне устоявшийся "Graph Data Base". А обобщение в том, что используется не только планарные графы, но и мультиграфы и т.п. Godligift 05:01, 25 мая 2012 (UTC)

Может быть, я отстал от жизни (скорее всего, это так и есть), но я привык к трём принципиально различным моделям баз данных: реляционные (алгебра отношений), иерархические (отношение подчинения) и сетевые (когда каждый элемент базы данных может быть непосредственно связан с другим некоторой связью). Современные реализации, по моим представлениям, пытаются скрещивать различные принципы, но здесь вряд ли можно предложить что-то принципиально новое. А в Википедии лучше всего описывать именно принципы, а примеры применения (в случае показанной значимости этих примеров) могут служить лишь иллюстрацией общих принципов, но никак не могут подменить их. Само понятие графа столь общо, что мы можем попытаться буквально всё подвести под графовую модель и, тем самым, породить оригинальное исследование. Между тем, наша задача — описывать существующие подходы и технологии. --OZH 07:25, 25 мая 2012 (UTC)

в статье приведена ссылка на статью в которой показывается что есть граф базы данных. Godligift 12:50, 25 мая 2012 (UTC)

Рисунок "Графовая база данных с данными ключ-значение"

Вопрос про подпись к рисунку «Графовая база данных с данными ключ-значение». Вообще-то на рисунке нет ничего про ключ-значение. В узлах и дугах перечислены по несколько атрибутов (по три, если точно), а вовсе не ключ и значение. Тогда зачем такая подпись? Евгений Мирошниченко 07:10, 24 мая 2012 (UTC)

• Не спрашивайте меня по каждому исправлению, я не изверг и не фундаменталист своих идей. Я уже сказал Правьте смело. Если возникнут трения это не от ваших правок, а от наших позиций и не более. Если хотите исправить и дополнять правьте. Во французской статье есть ещё один рисунок, но этот мне понравился больше и просто есть разные представления данных для графовых баз данных, поэтому такая подпись Godligift 07:18, 24 мая 2012 (UTC)
• Рисунок не очень удачен. Для раскрытия темы. Увы. :-( --OZH 20:00, 24 мая 2012 (UTC)

О сравнении графовых и реляционных БД

В книге Graph Databases приведен конкретный пример, иллюстрирующий превосходство графовых БД над реляционными на конкретном примере, сам пример взят из источника, к которому у меня нет достуа http://www.manning.com/partner/. Хотелось бы найти более солидный источник, на основе которого можно было бы грамотно написать анализ. Речь не идет о том, что однозначно "лучше", а в каком именно случае и какие компромиссы при этом сделаны (например, в NOSQL отказываются от ACID и вместо него стремятся к BASE). Например, по указанному источнику в графовых БД видятся как минимум два преимущества (по сравнению с реляционными БД): высокая производительность на специфических задачах (которые однако довольно часто встречаются в практике) и более естественное и гибкое представление (схема) данных, тогда как в РСУБД на практике полная нормализация приводит на ряде задач к неэффективным запросам (из-за JOINов) и поэтому приходится делать компромиссы. Если кратко, есть ли еще подходящие АИ, которые нейтрально оценивают БД, основанные на различных моделях данных? Или же миф 80х-90х о повсеместном превосходстве реляционной модели продолжает преобладать? РоманСузи 10:00, 4 мая 2013 (UTC)

Любое сравнение производительности конкретных СУБД вне официальных тестов, например, tpc не имеет никакой ценности. Поясню: любая мощная СУБД имеет множество настроек, сильно влияющих на производительность. При этом настройки by default далеко не всегда хороши, а для некоторых специфичных задач и вовсе никуда не годятся. Поэтому официальные тесты СУБД проводятся на определённой аппаратуре с определёнными настройками, причём именно для данного теста. Это позволяет достигнуть хоть какой-то объективности. Представьте себе, что некто сравнивает два свежекупленных автомобиля, но при этом не обращая внимания на то, что у одного летняя резина, у другого зимняя, у одного коробка-автомат, у другого — механика. Много ли ценности будут иметь выводы о сравнении скорости и манёвренности этих автомобилей?

Второе: при тестах имеют значения объёмы и типы данных. Одна и та же задача на небольших объёмах может привести к победе одной СУБД, а на больших — к победе другой СУБД. Многократно видел, как какой-нибудь кулибин склепает свою «крутую СУБД» и на форумах пишет, что по его тестам родимая поделка дерёт по скорости ваш жалкий Oracle (SQL Server и т. д.) в хвост и в гриву. Потом добрые люди несказанно огорчают убогого, показывая ему, что вот на таких-то объёмах его система вообще на будет работать. Что он настроил СУБД-конкурента неоптимально. Что он неправильно создал индексы. Что если тестировать не на строках, а на числах (или наоборот), то результаты резко меняются. Что если, скажем, подключить проверки различных ограничений целостности, то его чудо-система вообще затыкается. А если всё это делать транзакциями (как положено), то его поделка вообще громко причмокивает, а возможно, что в ней поддержки транзакций-то вообще нет. И так далее. Поэтому задача грамотного сравнения СУБД принципиально не может быть выполнена дилетантски.

Третье. Сравнивать модели данных по производительности могут только скорбные разумом. У модели данных нет производительности. Модель данных — это чистая абстракция. Производительность может быть у конкретной реализации, то есть у конкретной СУБД. А реализации могут быть весьма разными по производительности. Могу напомнить, что после публикации работ Кодда первые реляционные СУБД долго были намного-намного медленнее всех конкурентов. Но с годами появились реализации, которые всех догнали и даже зачастую перегнали. И теперь представьте себе, чего стали с этого момента стоить публикации о том, что реляционная модель данных сильно проигрывает в производительности иерархической модели. И теперь представьте себе, что некто даже написал это в книжке и даже привёл «пример» сравнения двух СУБД про производительности, который «убедительно показал его правоту».

Что касается фразы про «более естественное и гибкое представление», то подобным заявлениям сто лет в обед, но они при тщательном рассмотрении не выдерживают критики. А когда я вижу фразы типа «полная нормализация приводит на ряде задач к неэффективным запросам (из-за JOINов)», это уже практически диагноз их авторам. ◦ Евгений Мирошниченко ◦ 03:49, 6 мая 2013 (UTC)

Тем не менее, попытки сравнения есть. Например, Neo4j и MySQL. http://cs.olemiss.edu/~ychen/publications/conference/vicknair_acmse10.pdf РоманСузи 13:16, 6 мая 2013 (UTC)

1. Никто и не говорит, что не нужно учитывать более тонкие факторы. На практике, однако, при подборе БД для некоторой задачи или класса приходится делать допущения. Аналогично сравниваются разные файловые системы, операционные системы и т.п. 2. Возможно, я несколько выдрал пример из контекста. Тем не менее, в примере, на который ссылается указанный в статье источник, причмокивает как раз реляционная СУБД на некотором объеме данных. С другой стороны, я завел этот разговор не для того, чтобы что-то доказать. Меня интересует объективное описание графовых БД для википедии. Сам я ими не занимаюсь, но нахожу верю, что они займут свою нишу. 3. О моделях данных. Разумеется, их нельзя напрямую сравнивать. Но при реализации используются некоторые алгоритмы, а их можно сравнивать не только эмпирически, но и теоретически - по вычислительной сложности, по объему требуемой памяти. Кроме того, можно сравнивать "юзабилити" реляционной модели и графовой. Приведенный источник говорит о значительном превосходстве графовой модели, так как она более естественна для человеческого мышления. Та же ER-диаграмма есть напрямую "схема" графа, тогда как для СУРБД над ней нужно колдовать, после чего те самые JOIN оптимизировать, которые мало для кого естественны. Пункт 3, к сожалению, пустой обмен мнениями. РоманСузи 16:34, 6 мая 2013 (UTC)

1) Это яркий пример дилетантской попытки сравнения. Там в статье всё плохо: название, терминология, цель, средства, описание эксперимента, проведение эксперимента.

Подробнее

Название

Потенциально вводит в заблужение. Там нет сравнения a Graph Database and a Relational Database, есть, строго говоря конкретные Neo4j and MySQL

Терминология

Например, неграмотное использование терминов database и database system вместо DBMS, начиная с названия. Другой пример: некорректное использование термина effective вместо high-speed. По факту меряют скорость, а выводы делают про эффективность.

Цель

Некорректная. «Что эффективнее для такой-то задачи, какая-нибудь реляционная СУБД, например, MySQL, или какая-нибудь графовая СУБД, например Neo4j?» Некорректность в том, что перемешаны два совершенно различных вопроса. Вопрос 1: Что эффективнее для такой-то задачи, реляционные СУБД или графовые СУБД? Вопрос 2: Что эффективнее для такой-то задачи, MySQL или Neo4j? В общем случае ответ на вопрос 2 не отвечает на вопрос 1, а ответ на вопрос 1 должен искаться совершенно другими средствами, чем ответ на вопрос 2.

Средства

Если авторы ищут ответ на вопрос 1, его нельзя решать просто сравнением двух «каких-то» представителей. Но даже если взялись за чемпионат, за сравнение двух представителей по скорости, так выбирайте лучших представителей. На олимпиадах страны выставляют своих лучших спортсменов, а не «типичных» спортсменов. Ну и почему для замеров производительности выбрана MySQL? Она вообще отсутствует в рейтинге tpc, см. Why no TPC benchmarks for MySQL? MySQL вообще изначально была ущербной системой, а её широкое распространение в своё время объясняется исключительно дефолтным включением в состав бесплатного комплекта Linux (Apache+MySQL+PHP). Плюс в MySQL нет средств для запросной работы с графами, таких как CONNECT BY в Oracle, рекурсивные запросы из стандарта SQL-1999, например Recursive CTE в MS SQL Server, или такой фишечки для работы с иерархиями как hierarchyid в MS SQL Server 2008.

Описание эксперимента

Не описаны настройки систем. Не описаны физические настройки базы для MySQL. Не описаны типы MySQL-таблиц (всякие эти ISAM, HEAP, MyISAM, InnoDB, BDB)? Какие были созданы, и созданы ли вообще, индексы (без этого вообще о чём говорить)? Тексты запросов отсутствуют, кроме двух самых маленьких. А без текстов запросов тоже выводы не сделать.

Проведение эксперимента

Как указано выше, задача специализированная, так её и надо было в РСУБД решать соответствующими штатными средствами, как я указал выше (CONNECT BY, RCTE, hierarchyid...). Ну допустим, отказались от этих средств. Но и здесь, грамотным физическим проектированием, использованием индексов, материализованных представлений можно добиться очень серьёзного сдвига в производительности запросов. Ничего не сделано. Наконец, отсутствие текста запросов не позволяет их оценить. А запросы можно очень даже по-разному написать, с огромной разницей в производительности. Даже приведённый текст простейшего запроса S0 позволяет это показать. Эти господа написали следующее:

SELECT COUNT(*)
FROM node
WHERE node.nodeid NOT IN (SELECT source FROM edge)
AND node.nodeid NOT IN (SELECT sink FROM edge);

А надо было вот так:

SELECT COUNT(*)
FROM node
WHERE
  NOT EXISTS
  (  SELECT * 
     FROM edge
     WHERE source = nodeid OR sink = nodeid
  )

Разница в производительности этих вариантов запросов может быть невероятно велика. Забавно, что даже для медленного исходного варианта S0 оказалось, что «The query to find orphan nodes resulted in fairly comparable results between the two systems».

---

2) > При реализации используются некоторые алгоритмы, а их можно сравнивать: это всё равно будет сравнение реализаций. Алгоритмы есть часть реализации, а не часть модели. В РМД даже индексы не часть модели, например, существуют решения вообще без индексов (модель Transrelational).

3) То, что якобы графовая модель более естественна для человеческого мышления, считаю ничем не обоснованным. Давайте так: я видел сотни документов, которые используются в предприятиях. Во всех этих документах помимо текста фигурировали таблицы: такие, сякие, эдакие. Графы, что характерно, не видел ни разу. Ни в одном документе. И пусть теперь мне кто-то попробует доказать, что людям всего милее, яснее и естественнее графы. Это я не к тому, что графы не нужны, очень нужны. Но не более нужны, чем прочее. А зачастую -- намного менее. От задачи зависит.

4) Предпоследнее предложение (про ER-диаграммы и т.д.), простите, не понял. ◦ Евгений Мирошниченко ◦ 04:11, 7 мая 2013 (UTC)

1) Ок. Статья плохая. Спасибо за критику. 2) Это понятно. РСУБД более сложная вещь, где применяется сразу много разных «элементарных» алгоритмов. Собственно, с графами та же история, если взять алгоритмы работы с разреженными матрицами (графы часто используются как модель для матриц и наоборот). Там тоже есть «слоты», позволяющие «вставлять» алгоритмы в зависимости от требуемых свойств. 3) Диаграммы Ганта, UML, блок-схемы разных видов в полном составе и т. д. Конечно, если бухгалтерию иметь в виду, то таблицы там более естественны. Полагаю, что таблицы-против-диаграм не имеет однозначного решения. Я имел в виду сферу применения, где таблицы для данных — прокрустово ложе, из-за всевозможных исключений и необходимости постоянно дополнять шапку и т. п. 4) Цитата из Graph Databases (early edition), стр 44:

Ironically E-R diagrams immediately demonstrate the shortcomings of the relational model for capturing a rich domain. Although E-R diagrams allow relationships to be named (something which relational stores disallow, and which graph databases fully embrace) they only allow single, undirected named relationships between entities. In this respect, the relational model is a poor fit for real-world domains where relationships between entities are both numerous and semantically rich and diverse.

Разумеется, с помощью реляционной модели можно эмулировать все, что угодно, но при этом теряется непоредственность представления.

Общий смысл моих исканий в данной статье — найти чем графовые БД лучше. Для чего-то их создают и используют. Я не верю, что все такие дилетанты, что вместо Oracle или MySQL ставят Neo4j (и тем более разрабатывают). У графовых БД должна область, где они имеют серьезные преимущества. В масштабировании ли, в моделировании данных, в юзабилити или еще в чем — для этого я и пытаюсь найти источники. Заодно и для себя потихоньку выясняю этот вопрос. РоманСузи 05:40, 7 мая 2013 (UTC)

2) Я тогда не понял, какие алгоритмы в РСУБД вы имеете в виду и про какие слоты в РСУБД говорите? Я говорю, что модели данных некорректно сравнивать по производительности, так как производительность — это аспект конкретной реализации, включая физические структуры хранения и конкретные алгоритмы. При этом у разных СУБД реализация одной и той же модели данных может быть очень разная.

3) Бухгалтерию вообще не видел, не моё это. А вот производственный процесс: списки сотрудников и оборудования, планы показателей, планы работ, выдача заданий, контроль исполнения, журналы регистрации всякие, всевозможная отчётность, всевозможная аналитика, акты, заявки... Встречал и графы (схемы), но очень мало. Поэтому высказывания типа «графовая модель более естественна для человеческого мышления» для меня очень странно выглядят. При том, что как разработчик я постоянно с графами имею дело (UML, модели БД...)

Про необходимость «постоянно дополнять шапку» не понял. Вы про какую шапку? Атрибуты добавлять в отношения — это да, нередко приходится, но эта необходимость при любой модели данных существует. Нет проблем, приложение динамически считывает схему и под неё подстраивается. Ничего перепрограммировать зачастую вообще не надо. Так какие проблемы-то?

4) Насчёт цитаты. Долго перечитывал, пытаясь понять смысл. А он туманен. Такое ощущение, что авторы критикуют РМД за... недостатки ER-модели (или то, что они считают таковыми). Фраза с претензией „they only allow single, undirected named relationships between entities“ явно относится к „E-R diagrams“. Тут какая-то каша в голове, ER-модель и РМД суть модели разные, друг к другу отношения не имеют. Кроме того, там есть явно ошибочное утверждения про то, что „relational stores disallow“ якобы „relationships to be named“. Оставим на совести авторов непонятный термин „relational stores“, но по сути это неверно. „Relationship“ в РМД — это или самостоятельно отношение, которое явно „named“, либо внешний ключ, в которм „named“ все атрибуты, плюс отдельно „named“ и сам FK-constraint. Из-за всего этого последнее предложение, в котором РМД как бы вынесен «приговор», получается непонятно чем обоснованным, и теряет всякий смысл. Ну да, допустим, что в „real-world domains relationships between entities are both numerous and semantically rich and diverse“. РМД с этим неплохо справляется. Кроме того, есть давняя проблема с тем, что понятия entities и relationships на деле субъективны и зыбки. Сегодня это relationship, а завтра, эвон, уже entity с кучей атрибутов.

> При этом теряется непоредственность представления. Вы о каком представлении говорите, внешнем, концептуальном или внутреннем?

> Общий смысл моих исканий в данной статье — найти чем графовые БД лучше. Графовые БД — это реинкарнация сетевых БД. Это шаг назад на 60 лет. Увы, все те же причины, по которым РМД вытеснила сетевую МД, никуда не делись, и по прежнему актуальны. ◦ Евгений Мирошниченко ◦ 08:12, 7 мая 2013 (UTC)

2) Собственно, тут мы вроде как и не спорим.

3) Разумеется, это мое замечание не очень корректно, так как на уровне приложения уровень базы данных может быть слишком низок. С т.з. авторов Graph Databases, в графовой модели добавление новых атрибутов и даже миграция данных более безболезненна.

4) Насколько я понимаю, в графовой модели само отношение может иметь атрибуты, тогда как в реляционной отношение не является чем-то, кроме связи таблиц, а для отношения многие-ко-многим нужна еще и отдельная таблица (или я опять что-то неграмотное сказанул?). Разумеется, атрибутированное отношение можно и в РМД построить, добавив отдельную таблицу, где в неключевых колонках будут атрибуты отношения. Опять-таки, речь не об универсальности моделей, а о близости получаемых структур к моделируемой области. Там, где для графа вы пишите

(shakespeare)-[:WROTE { date : 1599 }]->(juliusCaesar)

в реляционной нужно три таблицы (date здесь и есть атрибут отношения) и записи в каждую (даже не уверен, можно ли одним INSERTом их загнать?). Косвенно (это уже моя идея), неадекватность ментальной модели (в голове разработчиков) и РМД в некоторых случаях видна в популярности ORM. Если модель такая естественная, то кому нужно переводить их на язык объектов? Я не знаю, что авторы книги имеют в виду (еще не до конца прочитал), но я понял, что графовая модель более соответствует ментальной модели предметной области в головах разработчиков, с помощью диаграмм легче наладить коммуникацию с неспецами в базах данных и программировании. Сам я нечасто занимаюсь проектированием под РСУБД, но когда приходится, иногда очень обидно, что с виду естественная конструкция чрезвычайно неэффективна на практике, и нужно подстраиваться под капризы конкретной базы данных. Конечно, ORM это частично берет на себя, но тем не менее. Если я возьмусь дописать данную статью, попробую изложить точку зрения NoSQL-истов в должной для нейтральности степени. Возможно, они не настолько владеют теорией, но их точку зрения нельзя скидывать со счетов.

Среди языков программирования по сути то же самое: есть основанные на списках, на множествах, на массивах, чистых объектах и т.п. вплоть до машинных кодов. Все это легко эмулировать друг через друга, но то, что естественно для одних задач, кажется неестественным для других. Доминируют тем не менее C и Java. Они тоже потеснили всех остальных.

представление: я имею в виду что в графовой модели требуется меньше действий по переносу концептуального представления на реализацию софта, чем в реляционной (во всяком случае, параллельные примеры в книге именно в этом убеждают). Полагаю, что разные модели имеют место быть и скорее всего каждое займет подобающее место. Возможно, из реляционных БД вырастут некие суперагрегаты. Оракл туда уже чего только не добавил для работы с деревьями, RDF и тд. Кстати, в англовики обсуждаемые идеи изложены, так что я не одинок. РоманСузи 17:38, 7 мая 2013 (UTC)

3) «Безболезненность» нужно рассматривать комплексно. Например, если приложение читает из базы XML и парсит его на лету, чего уж проще, казалось бы, для добавления атрибутов. Безболезненно? Однако теперь попробуем, скажем, раздать права пользователям на уровне отдельных атрибутов (кто может какие атрибуты читать и/или изменять). Внезапно это оказывается очень болезненно, настолько, что даже невозможно. Попробуем теперь задать декларативно ограничения целостности на атрибутах (например должно быть задано значение или атрибута A, или атрибута B, но не A и B одновременно). Выясняется, что это невероятно болезненно. Теперь попробуем задать фильтр для репликации данных между серверами, в котором фигурируют атрибуты. Выясняется, что и это невероятно болезненно. В итоге окажется, что в РСУБД все это делается по совокупности намного, намного более безболезненно, чем в указанном примере. С учётом того, что в РСУБД схема базы доступна для запросов, совсем несложно создавать приложения, которые совершенно безболезненно переносят изменения схемы в определённых таблицах. При этом сохраняя все другие бонусы наличия схемы, начиная с поддержки целостности и заканчивая производительностью.

4) Сразу порекомендую не переводить „relationship“ как «отношение», иначе его не отличить от реляционного «отношения» („relation“), что у вас и получилось. „Relationship“ поэтому обычно переводят как «связь». Так вот, в вашем же примере вижно, что РМД гораздо лучше справляется со связями и атрибутами. Там просто нет путаницы «сущность»/«связь», которую вы доступно описали. Ведь почему это связи с атрибутами — не сущности, понять невозможно. Скажите, брак между двумя людьми — это сущность или связь? Вот именно, что хоть так, хоть эдак. А в РМД этих проблем нет.

Что касается «близости получаемых структур к моделируемой области», то я только что показал, что это как посмотреть. Непонятно, что в реальном мире есть «дуги», что есть «узлы». Дорога между городами — это дуга? А почему не узел? У дороги куча атрибутов и куча собственных связей с другими «сущностями», кроме городов (проектная организация, строительная организация, ремонты....)? Какая уж тут адекватность. А в РМД всё просто и чётко: нет сущностей, нет связей, есть только факты. Например, есть факты о существовании городов, есть факты о существовании дорог, есть факты о проектных и строительных организациях, есть факты о связях городов с дорогами, факты о то, кто дороги проектировал, кто строил, факты о запланированных и выполненных ремонтах... Вот это как раз гораздо более адекватно моделирует предметную область. Я, кстати, так и не понял не понял из вашего примера какие проблемы с созданием трёх (или хоть трёх тысяч таблиц)? И зачем в один INSERT пытаться поместить запись трёх разных фактов, чем три INSERT'а плохи?

Что касается ORM, то преобразование структуры данных из базы в структуры данных приложения практически всегда необходимо. На внешнем уровне могут существовать различные приложения и различные способы представления одной и той же информации. Модель ANSI/SPARC заведомо говорит, что не надо путать то, как данные представлены в БД с тем, как данные представлены в том или ином приложении. Поэтому даже если мы имеет ОО-БД, то для конкретного ОО-приложения всё равно придётся осуществить маппинг, только он будет не ОРМ, а ООМ.

Что касается языков программирования, то у них задачи не такие, как у БД. Поэтому тут прямые аналогии проводить нельзя. ◦ Евгений Мирошниченко ◦ 05:38, 8 мая 2013 (UTC)

Спасибо за разъяснения. Предлагаю как-то закруглить данную дискуссию. Я, к сожалению, не крутой специалист в данных вопросах. Если найду материал, буду писать в статью, так как несмотря на разгром выше технология интересна. Насчет оценок могу воздержаться пока не будет сильных работ. Я полагаю, что по критике графовых БД еще меньше материала, чем "хвалебных". И старые источники (времен вытеснения сетевых баз данных) все-таки не пойдут. РоманСузи 15:18, 8 мая 2013 (UTC)